This PR fixes a gap in IRS 1099 data entry: the three OnValidate triggers on IRS 1099 Reporting Period, IRS 1099 Form No., and IRS 1099 Form Box No. in tableextension 10035 previously allowed a user to assign 1099 data to a vendor ledger entry even when the vendor had no IRS 1099 Vendor Form Box Setup record for that period.

The fix adds a new procedure CheckVendorSubjectFor1099Reporting in codeunit 10037 that does a keyed Get on IRS 1099 Vendor Form Box Setup using (PeriodNo, VendorNo) — the clustered primary key — and raises a clear error if no record exists. The procedure early-exits when PeriodNo is blank, so clearing any of the three fields remains unconditionally allowed. Each trigger guards the call with a non-blank check on the field being validated, which is the correct pattern. The Get key order matches the table PK (Period No., Vendor No.), so the existence check is accurate. The changes to IRS1099VendorTests.Codeunit.al adapt the existing ChangeIRSDataInVendorLedgerEntry test to supply a 1099-enrolled vendor for the ledger entry (required now that validation blocks non-1099 vendors) and add Round() to avoid the amount precision issue flagged in the pre-existing test failure list.

S1 - ValidateIRS1099FormBoxOnVendLedgEntryFor1099Vendor does not exercise the new check
The test validates IRS 1099 Form Box No. directly without first setting IRS 1099 Reporting Period, so CheckVendorSubjectFor1099Reporting receives PeriodNo = '' and exits immediately. The check is never reached, so the test would also pass for a non-1099 vendor. Consider setting a period on the entry before calling Validate("IRS 1099 Form Box No.", ...), which would actually exercise the guard added in this PR.

S2 - IRS 1099 Form No. trigger silently skips the check when period is blank
In the Form No. OnValidate, CheckVendorSubjectFor1099Reporting is called with "IRS 1099 Reporting Period" as the period. If a user sets Form No. before setting a period (possible on the page), PeriodNo is '' and the check exits early with no error. The primary flow (via Reporting Period validate → cascades Validate("IRS 1099 Form No.", '')) prevents this in practice, but a direct edit of Form No. without a prior period bypasses the guard.

Risk: The change adds validation at the table level on three OnValidate triggers in tableextension 10035. Any code path that calls Validate on these fields for a non-1099 vendor (batch imports, data migrations, or background jobs that set IRS fields without the full UI flow) will now raise an error where it previously succeeded silently. The IRS 1099 Propagate Vend. Setup report is unaffected because it only processes vendors that already have a setup record. Regression surface is limited to US localization only.

Necessity: The fix is clearly needed. Allowing non-1099 vendor ledger entries to carry IRS reporting data is a data integrity problem: those entries would be included in incorrect 1099 form calculations. The change is well-scoped and targeted.

The PR adds table-level validation so IRS 1099 fields on a vendor ledger entry cannot be set for a vendor that has no IRS 1099 Vendor Form Box Setup record for the selected period. The new round only removes unused local variables from two tests, so it does not change the product behavior.

The product fix is still targeted. It checks the vendor and period before setting the three IRS 1099 fields and still allows clearing the period. The remaining review points are about test strength and one direct-validation edge case from round 1.

None - the new commit only removes unused variables from tests.

Risk: The product change adds validation to posted vendor ledger entry IRS 1099 fields in the US IRS Forms app. This can block imports or background jobs that previously set these fields for vendors without 1099 setup, but that is the invalid data path the bug describes. The latest commit is test-only cleanup and has very low regression risk.

Necessity: The change is needed because non-1099 vendors should not carry IRS reporting data on vendor ledger entries. The scope remains narrow and tied to the bug scenario.

This PR blocks IRS 1099 fields on vendor ledger entries when the vendor has no IRS 1099 Vendor Form Box Setup for the selected reporting period. The latest commit addresses review feedback by making the positive test validate the reporting period and form before the form box, adding negative tests for Form No. and Form Box No., and changing the setup error to an ErrorInfo with a navigation action.

The main data-integrity path is now covered better. The validation still checks the keyed (Period No., Vendor No.) setup record before accepting non-blank IRS 1099 values, and clearing remains allowed because the helper exits for a blank period. I did not find a new issue in the latest commit, but one direct-validation edge case from the previous review remains open.

None - the new commit adds the missing test coverage for the main data-integrity path and improves the error message action. The remaining open point is still S2 from the earlier review.

Risk: The product change affects editable IRS 1099 fields on posted vendor ledger entries in the US IRS Forms app. It can now stop imports, page edits, or background code that tries to stamp IRS data on a non-1099 vendor, but that is the invalid data path the bug is meant to prevent. The latest commit is test and error-message work, so its new regression surface is small.

Necessity: The change is needed because non-1099 vendors should not carry IRS reporting data on vendor ledger entries. The scope remains narrow, and the tests now cover the financial data-integrity path that must be protected.